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In a September 2, 2010 non-final office action, Examiner rejected claim 1 (the only 
independent claim) under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 
7,061,876 ("Ambe") in view of United States Patent Application No. 2003/0223358 
("Rigby") and further in view of U.S. Patent No. 7,197,008 ("Shabtay"). 

Claim 1 distinguishes over the Ambe, Rigby and Shabtay references because it 
claims "receiving a packet, wherein the packet comprises a route indicator field further 
comprising at least one bit that indicates a link type" and "responsive to the packet being 
received after a time of failure along a communication link between two of the plurality of 
nodes and in response to a change of state of the at least one bit that indicates the link type 
in the route indicator field in response to a node detecting a link failure, transmitting the 
packet along a second route in the system to another node in the plurality of nodes, 
wherein the second route differs from the first route and is identified prior to the time of 
failure." 

In describing these limitations involving a route indicator field, the application 

states in relevant part: 

Figure 2 illustrates a packet format 20 according to a 
preferred embodiment and for use in connection with system 
10 of Figure la. Packet format 20 includes various fields as 
known in the Ethernet art, and only some of which are 
shown by way of example. These fields include a source 
address field 20 1, a destination address field 20 2 , a length 
field 20 3 and a data payload field 20 4 . Other fields, although 
not shown, may be included as also known in the art, such as 
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a preamble and a packet (or frame) start field. According to 
the preferred embodiment, however, packet format 20 
includes an additional field 2O5, referred to hereafter as a link 
type field 2O5. Link type field 20 5 is so named because, as 
shown below, the state of the field indicates the type of link 
on to which the packet is routed, with one state in field 2O5 
(e.g., 0) indicating a spanning tree link and another state in 
field 2O5 (e.g., 1) indicating a bypass link along system 10. 
In the preferred embodiment, link type field 20s is a one-bit 
field and it is contemplated that it could be a bit provided as 
an addition to existing Ethernet frames or, alternatively, it 
could be a bit that is already in the Ethernet frame yet where 
the function of that bit is changed to be consistent with the 
functionality described in this document as relating to link 
type field 20 5 . 



See Patent Application, p. 9. The Application further states: 

When a failure occurs in a link in system 10, that failure is 
detected according to known protocols. However, as an 
enhancement in a preferred embodiment, in response to the 
failure detection, a node within system 10 changes the state 
of link type field 2O5 so that each packet so changed will be 
routed along a bypass link, where recall by way of example 
that a binary value of 1 in link type field 20s causes this 
effect. Further, when a node within system 10 receives a 
packet with a binary value of 1 in its link type field 20 5 , the 
receiving node does not consult its forwarding table for 
purposes of further routing the received packet, but instead it 
consults its bypass table to determine the next route for the 
received packet. 



See Patent Application, p. 1 1. The route indicator field is further defined by Applicant as 
follows: 

In system 10, the route indicator field is a link type field 20 5 , 
operable to indicate that the packet is to continue along a 
spanning tree route or a bypass route. In system 10', the 
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route indicator field is a link set field 2C3, operable to 
indicate that the packet is to continue along a first set of links 
forming a first route, a second set of links forming a second 
route, and so forth for up to 2 M sets of links corresponding to 
a respective number of 2 routes. 

Examiner cited Shabtay as disclosing "responsive to the packet being received after 
a time of failure along a communication link between two of the plurality of nodes and in 
response to a change of state of the at least one bit that indicates the link type in the route 
indicator field in response to a node detecting a link failure, transmitting the packet along a 
second route in the system to another node in the plurality of nodes, wherein the second 
route differs from the first route." 

However, the cited portion of Shabtay (column 13, lines 3-18) discloses a local 
protection flag bit being added to the flags field of an operation, administration and 
maintenance (OAM) packet to notify edge nodes of the use of local protection tunnels 
along a path. The network processor associated with a failed link examines the inbound 
packets received from each link and if an OAM packet has also been received, it is 
checked if the packet is to be sent over the protection tunnel. In each OAM message to be 
rerouted to the protection tunnel, the network processor sets the local protection bit. 
Hence, Shabtay involves adding a flag bit to the flag field of the OAM packet rather than 
changing the state of an existing bit in an actual data packet (i.e. inbound packet) received 
at a node as required by the claims. In other words, Shabtay' s flag bit is not contained 
within the packet (i.e. data packet or inbound packet) but is added to a separate packet 
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(OAM packet) sent as a notification mechanism to indicate that local protection is in place 
along a certain path. 

Dependent claim 8 has been amended to explicitly state that the packet is a data 
packet in the present invention, as opposed to a OAM packet not containing the original 
data, to further distinguish from the disclosure of Shabtay. 

Applicant respectfully requests the Examiner withdraw the rejection and allow 
pending Claim 1. In addition, all claims depending from Claim 1 either directly or 
indirectly, including Claims 2-20, are also allowable for the reasons discussed in 
conjunction with Claim 1 . 
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CONCLUSION 

Applicant has made an earnest attempt to place this case in condition for allowance. 
For the foregoing reasons and for reasons clearly apparent, Applicant respectfully requests 
full allowance of all pending claims. If there are any matters that can be discussed by 
telephone to further the prosecution of this Application, Applicant invites the Examiner to 
contact the undersigned attorney at 512-306-8533 at the Examiner's convenience. 



Respectfully submitted, 



Date: November 29. 2010 By: /Gregory S. Donahue/ 

Gregory S. Donahue 
Reg. No. 47,531 

Correspondence Address: 

Alcatel Lucent 

c/o Galasso & Associates, LP 

P.O. Box 26503 

Austin, Texas 78755-0503 

(512) 306-8533 telephone 

(512) 306-8559 fax 
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